04. 이미지 최적화

📝 Contents

이미지의 중요성

  • 초고속 인터넷 시대에 접어들어 홈페이지 관리자들이 사용하는 이미지의 크기가 점점 커지는 추세
  • 이러한 추세는 고해상도 디스플레이의 발전과 연관이 있음
  • 해상도는 FULL HD, 4K UHD를 넘어 5K까지 개발되었고, 화소 밀도 또한 2x, 3x 등으로 점차 증가하고 있음
화소 밀도
  • 화소 밀도란 물리 스크린 공간 안에 얼마나 많은 픽셀이 압축되어 있는가를 의미
  • 화소 밀도는 1x, 2x와 같은 기기 픽셀 비율로 표현
  • 이것은 단위 길이 안에 존재하는 픽셀의 개수를 상대적으로 나타낸 단위
  • 모니터나 TV의 화소 밀도는 보통 인치당 픽셀 개수인 PPI(Pixel Per Inch)로 표현
  • 같은 1인치 안에 픽셀 수가 많으면 많을수록 화소 밀도가 높으며, 화소 밀도가 높을수록 더 선명한 화면을 표현할 수 있음
  • 단위 인치당 픽셀의 수가 2배 많다는 의미는 픽셀 크기가 1/2로 작다는 뜻
  • 웹 이미지의 크기를 얘기할 때 포인트라는 용어를 사용하기도 함
  • 40픽셀 이미지는 말 그대로 40픽셀의 너비를 가진 이미지 하나를 의미하는데, 40포인트 이미지는 1x에서는 40픽셀, 2x에서는 80픽셀, 3x에서는 120픽셀 너비를 가진 이미지를 뜻함
  • 따라서 웹 디자이너가 하나의 이미지를 사용할 때 디스플레이를 고려해 여러 크기의 이미지들을 모두 준비해야 하므로 훨씬 더 많은 노력이 필요


  • 사용자가 사이트에 처음 접속해서 보는 가장 크고 특색 있는 이미지를 Hero 이미지 또는 대문 이미지라고 부름
  • Hero 이미지의 로딩 속도에 따라 웹 사이트의 사용자들이 웹 사이트를 떠날지 말지가 달라짐
  • 이미지는 모든 웹 사이트의 기능과 성능 면에서 매우 중요한 역할을 함

디지털 이미지의 종류와 특성

  • 이미지를 잘 사용하려면 이미지의 종류와 특성을 잘 파악하고, 사용될 기기 타입과 용도에 맞춰 적절한 이미지를 선택해야 함
  • PNG는 핵심 이미지 레이어를 제외한 배경 이미지 레이어를 제거하여 전체 이미지를 투명하게 만들어 사용할 수 있는 알파 채널이라는 이미지 변환 기법을 이용함
  • 하지만 같은 품질의 JPEG 대비 사이즈가 커지기 때문에 투명 기능이 필요하지 않으면 JPEG 타입으로 변환해 사용하는 것이 사이트 성능을 위한 더 나은 선택임
  • 어떤 사용자는 이미지의 색상이나 밝기에 민감하게 반응할 수 있기 때문에, 거의 유사한 성능이라는 말에 논란의 여지가 있긴 함
  • 약간의 품질 차이가 제품 이미지나 판매 실적에 큰 영향을 줄 수 있지만, 약간의 품질 차이가 웹 성능에 큰 영향을 미칠수도 있음
  • 이미지 형식의 종류와 특징을 잘 파악하고 사용 목적 및 기기에 맞는 이미지를 선택하는 것이 웹 성능 향상뿐만 아니라 비즈니스에 도움이 됨

래스터 이미지 vs 백터 이미지

  • 래스터 이미지는 우리가 사용하는 대부분의 이미지 유형
  • 작은 사각형 모양의 픽셀에 표현하고자 하는 색상 정보를 입력해 이를 컴퓨터로 표현하는 방식
  • 사이즈가 크거나 품질이 더 좋은 이미지를 만들기 위해서는 그만큼의 정보를 담은 픽셀들을 추가해야 하므로 확장성이 떨어짐


  • 백터 이미지는 그리고자 하는 대상의 수학적인 정보를 제공
  • 컴퓨터가 그림을 그리듯 화면에 표현
  • SVG 파일이 W3C 표준 포맷으로 가장 많이 사용됨
  • 백터 이미지는 메타 정보를 담고 있으므로 화면이 커지거나 작아진다고 해서 이 정보가 달라지지 않음
  • 화면 스케일에 상관 없이 항상 선명한 이미지를 표현할 수 있지만, 그림이 복잡해지면 이를 표현하기 위한 정보가 기하급수적으로 늘어나며 이를 수학적인 정보로 표현하는 데에도 많은 제약이 있음
  • SVG 파일은 텍스트 기반 콘텐츠이므로 gzip이나 brotli 같은 텍스트 압축 기법으로 간단히 최적화 할 수 있음

무손실 이미지 형식 vs 손실 이미지 형식

  • 이미지 형식을 구분하는 또 다른 기준은 이미지 정보의 손실을 허용하는지 여부
  • 카메라로 사진을 찍어 RAW 형태로 저장한다면 사이즈가 크기 때문에 적절한 압축 기법을 이용해 사이즈를 축소해 저장
  • 이 과정에서 많은 이미지 정보가 삭제되거나 눈에 뜨일 정도로 품질 손상을 가져오는 경우도 있음
  • 손실 이미지 형식은 단순 복사를 하거나 저장할 때도 정보 손실이 발생할 수 있으므로 주의 해야함
  • GIF, PNG는 무손실 이미지의 대표적인 형식
  • JPEG와 WebP, JPEG XR, JPEG 2000과 같이 브라우저에 특화된 이미지 유형들은 손실 이미지에 해당
GIF
  • 인터넷이 활성화된 이래 가장 처음으로 등장한 이동식 이미지 형식으로써 아직까지 널리 사용됨
  • 몇 개 이미지를 묶어 짧은 움직임을 표현하는 애니메이션 기능을 제공해 웹 사이트뿐만 아니라 채팅 프로그램에서 이모티콘으로도 많이 활용됨
  • 사용할 수 있는 색이 256 컬러(8bit)로 매우 제한적
  • 트루 컬러 타입인 GIF 이미지로 변형할 수 있지만 파일 사이즈가 기하급수적으로 커져 비효율적임
  • 단순한 형태의 이미지 표현에 적합
PNG
  • 24비트 색상을 사용해 GIF보다 고품질로 이미지를 표현할 수 있음
  • 24비트 색상은 2의 24제곱승인 16777216개의 색상을 사용할 수 있다는 뜻
  • 웹 사이트의 알파 채널이라고 불리는 투명 기능 때문에 PNG가 많이 사용됨
  • 이 기능으로 백그라운드 투명도를 조절해 하나의 이미지에 여러 배경을 바꾸어 이미지를 다양하게 조합할 수 있음
  • 컬러 팔레트 PNG와 트루 컬러 PNG로 나눌 수 있음
  • 대부분 웹 사이트에서 사용되는 PNG는 알파 채널이 추가된 트루 컬러 PNG임
JPEG
  • 사진을 저장하는 사실상의 표준 형식
  • 디지털 카메라로 만들어지는 RAW 형식 파일은 크기가 너무 크기 때문에 네트워크로 전송하거나 웹에 게시하기 어려움
  • JPEG은 사람의 눈이 인식할 수 있는 색상만 남기고 나머지를 제거하는 방식의 기술을 이용하여 이미지를 표시하는 데 필요한 정보를 줄임
  • JPEG은 사용자가 그 품질 값을 결정할 수 있음
  • 품질 값을 100으로 해도 약간의 품질 손실이 발생하므로, 동일한 이미지를 여러번 편집해야하는 경우 비트맵이나 PNG처럼 무손실 이미지 파일을 사용하고 편집을 완료하면 JPEG으로 저장하는 것을 권함
  • PNG나 GIF에 비해 사진 이미지에 가장 적합한 형식임
JPEG 2000
  • JPEG의 단점을 보완하기 위해 개발됨
  • 새로운 압축 방식을 사용해 이미지 압축률을 높임
  • 무손실 압축 및 투명 기능, 애니메이션 기능을 지원
  • 많은 브라우저에서 지원하지 않고, 사파리 계열 브라우저와 iOS용 크롬에서 지원함 (jp2 or jpx)
WebP
  • 구글에서 개발하고 배포한 이미지 형식
  • JPEG 보다 개선된 공격적 압축 방식을 사용하여 파일 크기를 25~35% 정도 작게 할 수 있음
  • 무손실 압축, 애니메이션 기능, 투명 기능 지원
  • 점진적 데이터 전송 기능은 갖추지 못함
  • 일반적인 환경에서는 JPEG보다 좋지만, 사용자의 네트워크 품질이 낮은 경우를 고려하면 점진적 데이터 전송 기능이 빠진 점이 아쉬움
JPEG XR
  • 마이크로소프트사에서 개발한 이미지 형식
  • 향상된 압축 기법으로 파일 크기를 크게 감소 가능
  • 무손실 압축, 애니메이션 기능, 투명 기능 지원
  • 점진적 데이터 전송 지원
  • JPEG에 비해 R/G/B에 해당하는 색상 채널당 더 많은 수의 채색을 허용해서 표현할 수 있는 색상 범위를 확장
  • 인터넷 익스플로러와 엣지에서만 지원

이미지 변환 기법

무손실 압축

  • 무손실 압축을 위해서는 각 이미지 유형을 다르게 처리해야함
  • 그러나 대체로 스크립트를 통해 압축을 자동화할 수 있다는 장점이 있음
  • 각 이미지 유형별 무손실 압축은 책 4.3.1절 참고

손실 압축

  • 손실 압축은 특정 이미지 정보를 누락, 즉 손실시켜 파일 크기를 줄이는 방법
  • 사람의 시각은 명암 차이에 민감하지만 채색 차이에 크게 민감하지 않아서, 이미지 색이 비슷한 부분을 하나의 색으로 통일해 그만큼의 정보를 손실시켜도 사용자는 눈치채지 못함
  • 손실 압축은 원하는 만큼의 화질을 얻지 못하는 위험이 있음
  • 대부분 웹 사용자는 약간의 화질 차이는 신경쓰지 않지만, 100ms의 이미지 로딩 속도 차에는 오히려 민감하게 반응함
  • 사람이 품질 저하를 거의 눈치채지 못하면서 파일 크기를 가장 크게 줄일 수 있는 JPEG 품질은 100~75% 사이
  • 필자는 85~80% 정도의 품질의 이미지 손실 압축을 권장
  • 손실 압축을 하려면 기존 이미지 형식을 디코딩한 후 알고리즘에 따라 원하는 화질로 저하시켜 다시 원래 이미지 형식으로 인코딩 해야함
적절한 손실 압축 품질 지수
  • 각 이미지 특성에 따라 최적의 품질 수준이 달라짐
  • 손실 압축을 위한 최적의 품질 지수를 찾기 위해서는 원본 이미지와 손실 압축 이미지의 시각적 차이를 정량 계산할 수 있는 방법이 필요함
  • 대표적인 알고리즘은 다음과 같음
      1. 평균 제곱 오차 (Mean Squared Error, MSE)
      1. 최대 신호 대 잡음 비 (Peak Signal to Noise Ratio, PSNR)
      1. 구조적 유사도 (Structural Similarity, SSIM)
  • SSIM 값을 최대화할 수 있는 품질 지수를 찾아 손실 압축하는 것이 사용자 경험을 최대화하는 길
  • 주의할 점은 같은 화질의 이미지라 해도 손실 압축에 사용되는 라이브러리와 이미지 형식에 따라 SSIM 값이 다르다는 점
시각적 인지 능력을 고려한 자동 최적화 도구
  • SSIM이나 이와 비슷한 알고리즘을 사용해 사람이 인지하지 못할 정도의 이미지 최적화를 수행하는 것은 결코 쉽지 않음
  • 웹 사이트 내 모든 이미지 파일에 적용하려면 일련의 작업을 자동화해야 함
  • 자동 최적화 기능을 제공하는 무료 도구는 찾기 어렵고, 일부 유료 서비스는 다음과 같음
    • Akamai 같은 CDN 서비스 제공 업체에서는 이미지 트래픽 관련 자동 최적화 기능을 제공
    • Cloudinary는 클라우드상에서 이미지나 비디오를 관리하는 솔루션을 제공
    • JPEGmini는 잘 알려진 오프라인 최적화 도구
브라우저 특화 이미지로 변환
  • GIF, PNG, JPEG 처럼 모든 브라우저가 지원하는 표준 이미지 형식만 사용한다면, 최적화의 수고가 줄어듬
  • 그러나 최근 사용되는 기술적으로 진보된 이미지 형식들은 지원하는 브라우저가 달라 변환하기 어려움
  • 형태별 이미지 변환 도구들은 다음과 같음
    • WebP: libwebp
    • JPEG: OpenJPEG, Kakadu
    • JPEG XR, jxrlib
  • ImageMagick은 WebP 변환뿐만 아니라 JPEG 2000, JPEG XR로 변환도 지원함

반응형 웹에서의 이미지 배치 전략

  • 모바일 사용자들의 인터넷 웹 사이트 접속이 증가하면서 웹 사이트의 구현 추세에 변화가 생김
  • 처음에는 모바일 전용 사이트를 별도로 구축함
    • www를 m으로 바꾸는 엠닷(m.) 사이트
  • 엠닷 사이트는 몇 가지 문제점이 있음
    • 모바일 기기 크기가 다양해짐
    • 유지 보수의 문제점이 있음
    • 모바일 사용자의 사용성 문제점
  • 각종 기기가 제공하는 화면 크기에 맞추어 최적화된 웹 페이지를 제공하는 반응형 웹이 등장
  • 반응형 웹을 사용하면 유지 보수의 필요성이 없어지고, 모바일 사용자의 사용성도 개선됨
  • SEO 측면에서도 큰 이점을 제공함

반응형 웹의 문제점

  • 웹 페이지의 무게는 반응적이지 못함
  • 모바일 환경은 데스크톱 환경에 비해 열악하여 페이지 로딩 시간도 느려짐
  • LTE 환경에서 케이블에 비해 절반 정도의 데이터를 처리하고 2배 정도 시간 지연이 발생함
  • 데스크톱에 비해 모바일 기기의 GPU, 메모리 등의 사양이 좋지 않아 모바일 환경에서 페이지 로딩 시간은 더 길어질 것임

원인은 이미지

  • 반응형 웹은 미디어 쿼리가 사용자의 환경을 감지하고, 가변 그리드가 페이지 레이아웃을 구성하면, 그 안의 이미지가 자동으로 확장/축소되면서 화면에 적절히 표현됨
  • 화면 크기에 맞추어 이미지가 작아져도 파일의 크기는 작아지지 않음
  • 화면이 작아졌는데도 필요 이상의 웹 리소스들을 과하게 내려받는 현상은 크게 세 가지 유형으로 구분할 수 있음
내려받아 줄이기
  • 이미지 태그는 width, heigth를 명시하지 않으면 브라우저의 처리 성능을 저하시킴
  • 유동형 이미지는 고정 값 대신 전체 화면 대비 이미지 영역의 비율 값을 사용함
  • 브라우저는 큰 이미지를 다운받아 작게 축소하는 처리를 함
  • 결국 모바일 환경에서는 과도하게 큰 이미지를 다운로드하려고 네트워크를 낭비하고, 다운로드한 이미지를 축소하려고 처리 리소스와 시간을 낭비함
내려받아 숨기기
  • 데스크톱 화면이 모바일 기기에 비해 훨씬 크기 때문에 비즈니스를 위해 데스크톱 화면에 더 많은 정보를 나타내는 것이 유리
  • 테스크톱 화면에는 모바일 화면에서는 불필요한 리소스들이 존재
  • 불필요한 리소스들은 모바일 환경에서도 여전히 다운로드된 후에 CSS로 숨김
  • 브라우저는 CSS에 의해 숨겨진 이미지들도 모두 다운로드해 필요 이상으로 네트워크 자원을 소모하면서 로딩 시간을 지연시킴
화면 바깥 부분
  • 화면 바깥에 있는 이미지들도 화면에 보이지는 않지만 내려받아 숨기기처럼 모두 다운로드 됨

반응형 이미지

  • 위에서 말한 문제점을 해결하기 위해 사용자의 환경에 따라 그 환경에 적합한 이미지를 전송하면 됨
  • 다른 환경 조건에 반응해 그 환경에 적합한 상태로 변경해 제공되는 이미지를 반응형 이미지라고 함
  • 유동형 이미지와 다르게 사용자가 특정 환경에서 특정 이미지를 요청하면 그 환경에 맞도록 이미 변경된 이미지가 전송되는 것이 반응형 이미지

반응형 이미지 구현 방법

  • 반응형 이미지 구현은 크게 두 가지 측면에서 접근 가능
    • 프런트엔드 측면에서의 구현: <img> 태그의 srcset 속성이나 <picture> 태그 사용
    • 백엔드 측면에서의 구현: 정확한 클라이언트 환경을 서버에 전달하기 위해 Client Hints를 이용
  • 백엔드 측면의 구현 방안은 적응형 이미지 전략에서 상세히 설명
srcset과 size 속성
  • srcset은 이미지 태그의 속성으로 사용자의 다양한 환경에 따라 다른 이미지 URL을 지정할 수 있도록 함
  • 브라우저가 사용하는 연산 방식이나 메모리, 혹은 파워가 충분한지에 따라 낮은 해상도 이미지가 선택될 수 있음
  • srcset은 내려받아 줄이기 문제를 어느정도 해결해 주지만 이를 완벽하게 지원하지는 않음
  • 해상도별로 다른 비율의 이미지를 사용하거나 부분만 확대한 이미지를 사용할 경우 이미지가 비정상적으로 보일 수 있음
  • 따라서 동일한 이미지를 크기만 다르게 사용할 것을 권장함
<picture> 태그
  • 내부적으로 <source> 태그를 사용해 다양한 이미지 URL을 설정
  • srcset과 다르게 정의돈 조건에 맞는 이미지만 사용하도록 브라우저를 강제할 수 있음
  • 조건에 맞지 않는 이미지는 다운로드 하지 않아 내려받아 숨기기와 내려받아 줄이기 문제를 모두 해결하는 가장 효과적인 방법
  • 모든 브라우저가 지원하지는 않음
Art direction
  • 같은 이미지를 크기만 다르게 하는 것이 아니라 이미지의 특징이나 가치가 기기 특성에 따라 표현되도록 정교한 작업이 이루어지는 것을 Art direction이라고 함
  • 이미지 축소가 아닌 crop 기능을 이용해 적합한 이미지를 만들어야 함
  • Art direction을 적용하려면 개발 및 운영에 많은 시간과 비용이 요구됨
Client Hints
  • <picture> 태그와 srcset 속성은 브라우저에서 모든 처리가 이루어짐
  • 모든 처리를 브라우저에만 맡기기 어려워 웹페이지를 호스팅하는 서버에서 사용자 환경을 고려해 응답할 내용을 최적화한 후 브라우저에 전달하는 방안이 도입되고 있음
  • 사용자 환경을 서버에 표준 방식으로 전달하기 위해 Client Hints를 사용하도록 논의 중
  • Client Hints 헤더는 HTTP 헤더의 일부로 포함되어 전송됨
이미지 지연 로딩
  • 나타내지 않을 이미지를 처음부터 다운로드하는 것은 웹 성능을 저하시킴
  • 이런 경우는 자바스크립트를 사용한 지연 로딩 방법을 권장
  • 이미지 태그의 src에 가짜 이미지를 링크
    • 가짜 이미지는 1 x 1의 작고 투명한 파일이여야 성능에 영향을 주지 않음
  • 실제 이미지는 data-src 속성에 정의
  • onload 이벤트가 발생할 때 이미지가 현재 페이지에서 사용자들에게 노출될 수 있는 상태인지 테스트
  • 노출될 수 있는 상태라면 data-src에 정의된 실제 이미지 정보를 링크시킴
  • 실제 상황은 단순하지 않기에 지연 로딩을 지원하는 라이브러리가 많음
모바일 우선 접근
  • '모바일 우선'이란 반응형 웹을 개발할 때 모바일 기기에 적합한 페이지부터 개발하는 방법
  • 데스크톱 화면을 먼저 개발하면 데스크톱에 최적화된 이미지를 많이 사용함
  • 다음으로 모바일 화면을 개발할 때 이미지를 상당수 그대로 사용함
  • 이 경우 모바일 페이지 성능 저하로 사용자 불편을 야기함
  • 모바일 접속자 수가 데스크톱 접속자 수를 초과하였고 앞으로도 모바일 사용자 증가가 예상되는 만큼 모바일 우선 접근을 사용해야함

적응형 이미지 전략

  • 반응형 웹은 모든 클라이언트 환경에 같은 웹 페이지로 대응함
  • 반응형 웹은 하나의 이미지를 다운로드하기 위한 코드가 늘어나고 이미지가 많아질수록 웹 페이지 크기가 커져 사용자 기기에도 부담을 늘림
  • 이를 해결하고자 서버 측 반응형 웹 접근 방법이 등장함
  • 적응형 이미지는 서버 측 반응형 웹을 구현할 때 필수적인 이미지 호출 방식

적응형 이미지 아키텍처

  1. 요청 클라이언트 정보를 감지

  2. 클라이언트 맞춤형 데이터를 로딩하는 서버 로직 추가

  3. 적응형 이미지 아키텍처에서 가장 근본적이고 중요한 부분은 클라이언트의 정보를 어떻게 감지하느냐임

  4. 앞으로 HTTP 요청에 클라이언트 정보가 추가되어 Client Hints에 담길 예정이지만 Client Hints를 지원하는 브라우저가 적어 실제 사용까지 시간이 걸릴 것임
  5. HTTP 요청의 User-Agent 헤더를 통해 클라이언트의 정보를 알 수 있음
    • User-Agent에는 브라우저 정보와 버전, 플랫폼, 시스템, 기타 사용자 정보 등이 담겨 있음
  6. 원본 서버 앞에 리버스 프록시 서버 또는 애플리케이션을 두고, User-Agent 값을 기반으로 필요한 정보들을 수집해 사용자 정의 헤더나 쿠키에 넣어 서버로 보낼 수 있음
  7. 기기를 감지해 정보를 제공해주는 여러 솔루션이 있음 (책 4.5.1절 참고)

기기 정보에 따라 서버 로직 수행

  • 기기 검출 방안에 따라 관련 정보들을 수집했다면 클라이언트 환경에 맞는 이미지 파일을 링크에 연결함

브라우저별 이미지 전달

  • 브라우저별 이미지는 HTTP 요청의 Accept 헤더를 참고해 결정할 수 있음
  • 크롬은 Accept 헤더에 WebP 지원 여부를 표시하고 IE나 엣지도 Accept 헤더에 JPEG XR 지원 여부를 나타냄
  • JPEG 2000을 지원하는 애플 사파리는 Accept 헤더에 별도 표시를 하지 않으므로 기기 검출 솔루션에 의존해야함

캐시 고려 사항

  • 적응형 이미지는 동일한 URL을 사용해도 사용자 기기에 따라 서로 다른 이미지가 응답될 수 있음
  • 이에 따른 캐시 충돌 현상에 주의 해야함
  • 캐시 충돌 현상은 하나의 URL에 여러 개의 다른 콘텐츠가 응답할 수 있을 때 먼저 응답하는 콘텐츠만 캐시되는 현상
  • 이러한 현상을 피하려면 서버에서 응답할 때 Vary 헤더를 활용해서 특정 헤더에 따라 콘텐츠가 달라질 것이라고 캐시 서버에 알려줘야 함
  • CDN 서비스를 사용한다면 Vary 헤더를 사용하는 것보다 CDN 서비스에서 제공하는 캐시 키 정책을 수정하여 기기 정보를 추가하면 됨

💭 Insights

화소 밀도와 기기 픽셀 비율(DPR)의 관계

  • 책에서는 화소 밀도를 DPR (1x, 2x, 3x...) 로 표현한다고 나온다.
  • 또한 화소 밀도는 인치 당 픽셀수인 PPI이다.
  • 그렇다면 100 PPI인 모니터가 있고, 200 PPI인 모니터가 있으면 100 PPI 모니터는 1x이고, 200PPI 모니터는 2x인 것인가?
  • 아니면 100 PPI 모니터는 1/2x이고, 200PPI 모니터는 1x인 것인가?
  • 1x의 PPI는 몇인가?
  • 그리고 PPI가 인치당 픽셀이고 DPI는 인치당 Dot인데 왜 보통 모니터에 DPI를 얘기할까?


  • ppi와 dpi는 다른거지만, 관습적으로 이미지 해상도를 논할 땐 dpi=ppi로 간주하고, 프린터 스펙을 논할 땐 진짜 dpi를 언급한다고 한다.
  • 모니터는 보통 72dpi가 기준이 해상도였다가 요즘은 96dpi가 많이 보인다고 한다.
  • 스마트폰은 초창기에는 150 - 200 ppi 정도 였다가, 요즘 레티나 디스플레이가 나오면서 300이 넘어가고 600이 넘어가는 스마트폰들도 나온다고 한다.
  • 그럼 여기서 1x는 150ppi고 300은 2x 600은 4x인가? 무조건 그런것은 아닌 것 같다.
  • 화면 배율은 화면의 물리적 픽셀과 UI 요소의 논리적 픽셀 간의 배율을 나타내는 것이다.
    • 1x: 1 논리 픽셀 = 1 물리 픽셀
    • 2x: 1 논리 픽셀 = 2 x 2 = 4 물리 픽셀
  • 보통 모니터는 96dpi에 1x가 적용되고, 180dpi가 넘으면 OS가 '2x' 스케일링을 적용하는 것 같다.
  • 고밀도 디스플레이인 레티나 디스플레이에 2x, 3x가 적용된다는 것 같다.


  • 결론은 2x 디스플레이는 1px 당 2개의 실제 픽셀을 사용하는 것이고, dpi/ppi의 갯수랑은 직접적인 연관은 없지만 1x의 기준은 어느정도 있는 것 같다.
  • 그래서 레티나 디스플레이 처럼 dpi/ppi가 높은 고밀도 디스플레이에 2x, 3x를 적용할 수 있는 것 같다.

results matching ""

    No results matching ""